Google released a new tracking tool, server-side GTM. What is it all about? Should you use it? Can you use it? Everything you need to know, coming up. Today we're gonna talk about a hot topic in analytics deployment. It's server-side tracking.

Since Google just announced their GTM server-side tagging, I thought it'd be a good idea to catch everyone up on this new feature and how useful it will be for your tracking deployment. So what is server-side tracking all about? Well, to understand server-side tracking, we need to first understand client-side tracking. You see, previously we would go to a website by entering the URL into the browser. What happens in the background is that the browser connects to a server on the internet, and then we receive a document back that contains HTML, CSS, and JavaScript, which makes up our website. Now in all of these files that get downloaded, we also have our tracking codes. These get executed on our browser and then send data like the time and which page you are on back to the mother server, which is Google Analytics, or for example, Facebook ads. So there is a direct connection between your browser, and this is the client, and your tracking tools. And this is called traditional client-side tracking.

With server-side tracking, we don't have that connection. We actually build our own tracking server, which then connects directly to our different tools. But how does the tracking data get to our server? Well, we either send it still from the client side, or we could also send it directly from the web server or your application to your tracking server. From there, it then gets distributed to your tools. The big advantage here is that we potentially have to not send the data over and over again to these different tracking tools, but can simply send the data over once to our tracking server, and from there it gets distributed to our different tool. That's client-side tracking in a nutshell. It's important to notice that this is really not a new concept. Tools like Omnitrack have this approach, and we were actually able to send in data to Google Analytics from the server side by the measurement protocol as well.

But now what is this server-side GTM all about? Well, in Google Tag Manager, you can now choose to create your own server in the Google Cloud to play the role of the tracking server. So data can be sent to the server, and then it gets picked up and you can configure your triggers to fire any kind of tags and forward that data on to your tools like Google Analytics. Pretty neat, right? There's a catch though.

First of all, you need to set it all up. And although the setup is not really too hard, it takes a while to get used to the new paradigm that this new server-side tracking technology brings with it. So data gets actually sent from your browser to your GTM server-side instance, and there it needs to be claimed by something called GTM clients. These then parse the data and you can trigger your tags just like in your normal GTM. But the problem right now at least is that at the moment there are not many templates out there for the clients of a server-side GTM and also not many tags out there. So even if you wanted to, it's really hard to migrate your data from client-side to server-side right now. I'm sure that's going to change in no time with the awesome GTM community that always produces these new templates, but we just have to wait and see for that one.

The second thing you need to be aware of is just like you are building your website on a web server on the internet, you're building here a tracking server, and this actually is not for free. Google gives you a free sandbox at the beginning to test out your tags and get it all configured, but if you want to run this on a live website, you need to upgrade, and that costs you at least $100 per month. But maybe we'll see that also coming down in cost because this is actually a Dockerized instance. You could take it over to another cloud platform and deploy it there, and maybe there will be specialized vendors there in the future that will bring down the price.

All right, now that you have this all set up and understand what it's doing. What are maybe some use cases why you would prefer using server-side GTM right now? Well, the big factor here is you have more control. Since you are sending data to your own server, and once the data arrives there, you can really do whatever you want with it. You can change it around, manipulate it, and add data, or you could also just ignore it. So for example, you could make sure that personal identifiable information is being stripped out of the request before you send it on, or you could send certain data requests only to one specific tool, or you could also add data like an API key that you want to keep secret from the client. There are many more such examples of creative uses of Google Tag Manager server-side tracking, but the point being here, you have much more centralized control on how to deal with the data before it then goes on to your tracking vendors.

On the client side with this approach, things would also change because now you only be sending one tracking point over to your server-side GTM, and from there, the client can distribute it to all of these different tools that obviously would then save resources, data, and could improve site speed. Another advantage on that client side with this one request is that you wouldn't be sending your data over to, let's say, googleanalytics.com, but to your own domain like data.yourwebsite.com, and ad blockers actually use that URL oftentimes. They can recognize googleanalytics.com, but are less likely to notice when you send data to your own tracking domain. Therefore, it could be a good way, at least for right now, to circumvent ad blockers and get more data into your system. That of course could change at any point in time when the ad blockers catch up and find out we are all using this technique, and then they will shut probably down this loophole as well. But in the same vein, we could also look at ITP, so the intelligent tracking prevention by the Apple and Safari browsers. The restrictions that were introduced there are that the cookie expiration date are set differently, depending on how you set your cookies. So cookies would only be valid in the Safari browsers from one to seven days, depending on how you set them.

But with server-side tracking, you can actually send something called an HTTP cookie, which currently doesn't fall under these restrictions, thus getting around the ITP, at least partially. Again, of course, this could change at any point in time once the WebKit browsers change their approach there as well. So maybe that sounds already like some pretty compelling use cases to you that you want to implement.

So should you start using GTM server-side right now? Well, I say think twice. It comes with some drawbacks. Don't forget the cost. You will need to pay money for this. If you are planning on using server-side GTM for you or your client's website, you need to set this up on a server and pay for it on a monthly basis. You should also not underestimate the costs that come with potentially migration of your tracking codes onto the server-side instance. You would need to re-implement and then test this all again. But then you also need to remember this is still in beta. There are not many templates inside of GTM server-side yet. So unless you are a developer wanting to write your own templates, you can't really migrate everything over from the client-side over to the server-side quite yet. But okay, if that doesn't hold you back and you're one of the enthusiasts who really wants to tinker with this tech, you can get started right now. It's pretty easy to set up.

Overall, I'm super excited about GTM server-side tracking and what it will let us do in the future. It might not be entirely there yet, but just for us, there are already a lot of brainteeth of what we could change our tracking around and what we could do and all the different possibilities that are going around in my head right now. But what do you think? Will server-side tracking solve your tracking problems at the moment, or will you actually try it out or will you stick to your client-side implementations and not really care about it for now?